Skip to content

feat(config): one-time config.toml migration to state.toml + keychain#248

Open
LorrisSaintGenez wants to merge 8 commits into
feat/profile-deprfrom
feat/profile-migration
Open

feat(config): one-time config.toml migration to state.toml + keychain#248
LorrisSaintGenez wants to merge 8 commits into
feat/profile-deprfrom
feat/profile-migration

Conversation

@LorrisSaintGenez

@LorrisSaintGenez LorrisSaintGenez commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

What

One-time, first-run migration of legacy config.toml profiles to state.toml + OS keychain

  • Trigger: at startup when config.toml exists but state.toml doesn't (its absence = "not migrated"). Runs before credential resolution; a failure never blocks the command and retries next run.
  • Per profile: api_key/crawler_api_key → keychain; alias, search_hosts, crawler_user_idstate.toml; current_application_id = the default profile. admin_api_key excluded.
  • Atomic: keychain first, state.toml last (temp + rename). Empty config still writes an empty state.toml so the trigger stops firing.
  • Skip rules: missing application_id/api_key skipped; same application_id → default wins; undecodable profiles or unparseable config abort/skip instead of crashing.

config.toml is never modified.

Test

  • Make sure you have a config.toml profiles file (you should if you ever used the CLI with a profile before)
# remove if it already exists
rm -f ~/.config/algolia/state.toml

# any command triggers the migration once, even this one
go run ./cmd/algolia

# Should contain current_application_id + [applications] with, for each app:
# alias and crawler_user_id (if present in the config.toml file)
cat ~/.config/algolia/state.toml

# macOS: the migrated key is in the keychain (replace <APP_ID>; go-keyring stores it base64-encoded)
security find-generic-password -s algolia-cli -a "app:<APP_ID>" -w | sed "s/^go-keyring-base64://" | base64 -d

# run it again: no re-migration, no logs
go run ./cmd/algolia

GROUT-363

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
@codacy-production

codacy-production Bot commented Jun 12, 2026

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 51 complexity · 16 duplication

Metric Results
Complexity 51
Duplication 16

View in Codacy

TIP This summary will be updated as you push new changes.

LorrisSaintGenez and others added 3 commits June 12, 2026 14:14
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two startup-path regressions found while testing edge cases:

- An undecodable profile (root-level scalar, unconvertible field type)
  hit ConfiguredProfiles' log.Fatalf and bricked every command, --help
  included, forever (state.toml never written). The migration now
  decodes profiles itself and skips undecodable entries with a log.
- An unparseable config.toml was silently read as zero profiles, so an
  empty state.toml marked the migration as done forever. Migrate now
  aborts when config.toml cannot be parsed and retries on the next run.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The remaining non-secret profile data moves with the migration so it
survives the eventual config.toml removal. GetSearchHosts and
GetCrawlerUserID gain a new-model branch: the resolved application's
state.toml entry answers first, an empty value falls through to the
legacy config.toml lookup while both models coexist. admin_api_key
stays excluded as decided on the ticket.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@LorrisSaintGenez LorrisSaintGenez self-assigned this Jun 15, 2026
LorrisSaintGenez and others added 3 commits June 15, 2026 08:23
Legacy migrated keys have no UUID, so without omitempty every migrated
entry serialized a noisy api_key_uuid = "". The field is only set by
new-model writes (app create/select); omitting the empty value matches
search_hosts/crawler_user_id and reads back identically.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The select picker decorated choices from config.toml profiles only, so
apps configured under the new model showed as unconfigured. It now marks
an app "(configured)" when state.toml holds an entry for it, falling back
to legacy config.toml profiles while config.toml is still supported.

Adds Config.ApplicationInState for the state-only lookup.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… auth

Two follow-ups from auditing the command tree against state.toml:

- application list marked apps configured from config.toml profiles only,
  so new-model apps showed as "(not configured)". It now uses the same
  state-first/config-fallback check as the select picker, centralized in
  apputil.ApplicationConfigured.
- describe walks the command tree and needs no credentials, but lacked
  skipAuthCheck so it failed on a machine with nothing configured. It now
  skips the auth check.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@LorrisSaintGenez LorrisSaintGenez force-pushed the feat/profile-migration branch from 48629f8 to 383dd0d Compare June 15, 2026 15:50
When state.toml resolves a current application but its key isn't in this
machine's keychain (e.g. state.toml synced across machines without it),
GetAPIKey/GetCrawlerAPIKey returned the generic "not configured yet". The
error now names the application and points to the fix (`application
select` / `auth crawler`, or the matching env var). Re-authenticating
rewrites the keychain entry, so it restores a working state.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@LorrisSaintGenez LorrisSaintGenez marked this pull request as ready for review June 15, 2026 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant